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Dear Sir: 

This Corrected Appeal Brief is filed in response to the Notification of Non-Compliant 
Appeal Brief mailed on July 1 8, 2007. As required, this Brief is filed not more than one month 
after the Notification of Non-Compliant Appeal Brief. The only changes made in this Corrected 
Appeal Brief as compai-ed to the Appeal Brief filed June 5, 2007, is that the Summary of 
Claimed Subject Matter is updated to identify the corresponding claims being summarized. 
Thus, the substantive arguments of this Corrected Appeal Brief remain the same as the 
originally-filed Appeal Brief of June 5, 2007. 



Application No.: 09/880,631 



Confirmation No.; 5913 



Filed: June 12, 2001 



Art Unit: 2157 



CORRECTED APPEAL BRIEF 



The Notification of Non-Compliant Appeal Brief asserts that in the summary of claimed 
subject matter, "the claimed invention is not mapped to identify the independent claims 1,11 and 
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26, which shall refer to the specification by page aiid line number and to the drawings, if any." 
While the independent claims 1,11, and 26 were summarized in the Appeal Brief of June 5, 
2007, with references to the specification (by page and line number) and to the drawings (see 
pages 4-7 of the June 5 Appeal Brief), the summary provided in that Appeal Brief did not 
expressly identify those claims. Appellant is aware of no rule that requires the summary of an 
appeal brief to expressly identify which claim is being described, as the rules appear to instead 
merely require that the claimed subject matter be summarized (without a requirement that each 
claim being summarized be expressly identified in the summary). However, for the convenience 
of the Board, an express identification of the claims being summarized in the summary section of 
the Appeal Brief is provided in tliis Corrected Appeal Brief Accordingly, in an attempt to 
address the Notification of Non-Compliant Appeal Brief, Appellant hereby submits this 
"Corrected Appeal Brief which is substantively the same as the Appeal Brief filed June 5, 2007, 
but which further adds corresponding claim identifications in the Summary of the Claimed 
Subject Matter section. 

The fees required under § 41.20(b)(2) were dealt with in the Appeal Brief filed 
September 19, 2005. No further fees are believed to be due for this Appeal Brief 

This brief contains items under the following headings as required by 37 C.F.R. § 41 .37 
and M.P.E.P. § 1205.2: 



I. 

II. 

III. 

IV. 

V. 

VI. 

VII. 

VIIL 
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Related Proceedings 
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I. REAL PARTY IN INTEREST 

The real party in interest for this appeal is: 

Hewlett-Packard Development Company, L.P., a Texas Limited Partnership having its 
principal place of business in Houston, Texas. 

0. RELAI^ED APPEALS AND INTERFERENCES 

There are no appeals, interferences, or judicial proceedings which will directly affect or 
be directly affected by or have a bearing on the Board's decision in this appeal. 

III. STATUS OF CLAIMS 

A. Total Number of Claims in Application 
There are 37 claims pending in application. 

B. Current Status of Claims 

1. Claims canceled: None 

2. Claims withdrawn from consideration but not canceled: None 

3. Claims pending: 1-37 

4. Claims allowed: None 

5. Claims rejected: 1-37 

C. Claims On Appeal 

The claims on appeal are claims 1-37 
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IV. STATUS OF AMENDMENTS 

A first Office Action was mailed for this application September 22, 2004. In response, 
Applicant filed an Amendment on December 22, 2004, which presented an amendment to claim 
5. A Final Office Action was then mailed April 20, 2005. Applicant did not file an amendment 
in. response to the Final Office Action, but instead filed a Notice of Appeal on July 1 9, 2005 and 
filed a supporting Appeal Brief on September 19, 2005. The rejection at issue in that appeal was 
that all of claims 1-37 stood rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. 
Patent No. 6,775,692 issued to Albert et al ^Albert). 

In response to such Appeal Brief, the Examiner did not submit an Answer, but instead 
reopened prosecution and mailed an Office Action dated April 6, 2006 which raised a Restriction 
Requirement. Applicant traversed tlie Restriction Requirement in a response dated May 5, 2006, 
and the Restriction Requirement was withdrawn in an Office Action mailed July 27, 2006. 
However, the July 27, 2006 Office Action rejected the claims on new grounds, namely rejecting 
all of claims 1-37 under 35 U.S.C. § 103(a) as being unpatentable over Albert in view of U.S. 
Patent No. 5,774,660 issued to Brendel et al {""Brender). Applicant submitted a response on 
October 25, 2006 which did not amend any of the claims, but instead pointed out that Brendel 
does not correct the deficiencies of Albert that were noted in the previous Appeal. 

A Final Office Action was then mailed January 12, 2007 that maintained the rejection of 
claims 1-37 under 35 U.S.C. § 103(a) as being unpatentable oy&t Albert in view of Brendel. 
Applicant did not file an amendment in response to the Final Office Action, but instead filed a 
Notice of Appeal, which tliis brief supports. Thus, the claims on appeal are those claims rejected 
in the Final Office Action mailed January 12, 2007, and a listing of those claims are provided in 
Appendix A hereto. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

The following provides a concise explanation of the subject matter defined in each of the 
separately argued claims involved in the appeal, referring to the specification by page and line 
number and to the drawings by reference characters, as required by 37 C.F.R. § 41.37(c)(l)(v). 
Each element of the claims is identified by a corresponding reference to the specification and 
drawings where applicable. Note that the citation to passages in the specification and drawings 
for each claim element does not imply that the limitations firom the specification and drawings 
should be read into the corresponding claim element. 

According to one claimed embodiment of the present invention, such as that of 
independent claim 1, a method of TCP state migration in a communication network comprises 
establishing a TCP/IP communication session between a client computer (e.g., client 410 of 
Figure 4) and a first server computer (e.g., server 450 of Figure 4). The first server computer is 
pai1 of a plurality of server computers forming a web cluster containing information (e.g., web 
cluster 490 of Figure 4). The communication session is established for the transfer of data 
contained within the information. The method further comprises handing off the communication 
session to a selected server computer (e.g., server 452 of Figure 4, and see page 23, lines 9-13 of 
the specification) from the first server computer over a persistent control channel using TCP 
handoff modules (e.g.. Upper TCP module 522 and Bottom TCP module 524 of Figure 5C, and 
see page 8, line 25 - page 1 1, line 6, and page 29, line 27 - page 30, line 6 of the specification) 
that are dynamically loadable (see page 17, line 24 - page 1 8, line 15 of the specification) within 
TCP/IP stacks in operating systems located at both the first server computer and the selected 
server computer, that implement a TCP handoff protocol that works within kernel levels of an 
existing TCP/IP protocol (see page 23, line 21 - page 26, line 29 of the specification). The 
method further comprises migrating a first TCP state of the first server computer to the selected 
sei-ver computer, and a second TCP state of the selected server computer to the first server 
computer over the control channel (e.g., page 10, line 26 - page 11, line 28 of the specification). 

In one embodiment, such as that of dependent claim 2, establishing the TCP/IP 
communication session further comprises receiving a SYN packet ixom the client at a first BTCP 
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module located at the first server computer (block 1010 of Figure 10); sending the SYN packet 
upstream to a first TCP module located above the first BTCP module in a first operating system 
of the first server computer (block 1020 of Figure 10); receiving a first SYN/ACK packet from 
the first TCP module (block 1030 of Figure 10); parsing the first initial TCP state from the first 
SYN/ACK packet, including a first initial sequence number for tlie first TCP module associated 
with the TCP/IP communication session (block 1040 of Figure 10); sending the SYN/ACK 
packet to the client (block 1050 of Figure 10); receiving an ACK packet firom. the client at the 
first BTCP module (block 1060 of Figure 10); sending the ACK packet to the first TCP module 
(block 1070 of Figure 10); receiving a web request packet associated with the TCP/IP 
communication session at the first BTCP module at the first server computer (block 1080 of 
Figure 10); and storing the SYN, ACK and the web request packet at the first server computer 
(block 1090 of Figure 10). 

In one embodiment, such as that of dependent claim 3, handing off the communication 
session further comprises examining content of the web request packet; detennining which of the 
plurality of server computers, a selected server computer, can best process the WEB request 
packet, based on the content (page 1 0, lines 7-16 of the specification); sending a handoff request 
fi-om said first BTCP module to a second BTCP module at the selected server computer over the 
control channel, if the selected server computer is not the first server computer; including the 
SYN packet and the ACK packet in the handoff request packet; changing a first destination IP 
address of said SYN packet to a second IP address of said selected server computer, at said 
second BTCP module; sending said SYN packet to said second TCP module; receiving a second 
SYN/ACK packet at said second BTCP module; parsing said second initial TCP state from said 
second SYN/ACK packet, including a second initial sequence number, for said second TCP 
module, that is associated with said TCP/IP communication session; changing a second 
destination IP address of said ACK packet to said second IP address, at said second BTCP 
module; updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; sending said ACK packet that is updated to said second 
TCP module; and sending a handoff acknowledgment message to said first BTCP module. 
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According to another claimed embodiment, such as that of independent claim U, a 
method of TCP state migration in a communication network comprises establishing a TCP/IP 
communication session between a client computer (e.g., client 410 of Figure 4) and a first server 
computer (e.g., sender 450 of Figure 4). The first sender computer is part of a plurality of server 
computers forming a web cluster containing information (e.g., web cluster 490 of Figure 4), and 
the communication session is established for the transfer of data contained within the 
information. The method further comprises monitoring traffic associated with establishing said 
TCP/IP communication session to understand a first initial TCP state of flie first server computer 
associated with the TCP/IP communication session, at a first bottom-TCP (BTCP) module at the 
first server computer (Bottom TCP module 524 of Figure 5 and BTCP module 830 of Figure 8, 
and see page 9, lines 16-20 and page 1 1, lines 8-1 1 of the specification). The method further 
comprises receiving a web request associated with the TCP/IP communication session at the first 
BTCP module at the first server computer (block 910 of Figure 9 and block 1310 of Figure 13, 
and see page 10, lines 7-8 of the specification). The method fiirtlier comprises examining 
content of the web request, and determining which of the plurality of server computers ("a 
selected server computer") can best process the web request, based on the content (block 930 of 
Figure 9, and see page 10, lines 13-16 of the specification). The method further comprises 
handing off the communication session to the selected server (e.g., server 452 of Figure 4) 
computer from the first server computer over a persistent control channel, if the selected server 
computer is not the first server computer {see page 10, Hne 26 - page 11, line 28 and page 23, 
lines 9-13 of the speci fication). The method further comprises monitoring traffic associated with 
handing off the TCP/IP communication session to understand a second initial TCP state of the 
selected sender computer associated with the TCP/IP communication session, at a second BTCP 
module at the selected serv^er computer (e.g., BTCP module 870 of Figure 8, and see page 12, 
lines 1-13 of the specification). The method fiiillier comprises migrating the first initial TCP 
state to the selected ser\'er computer over the control channel, such that the second BTCP 
module can calculate a first TCP state for the first server computer in the TCP/IP communication 
session (e.g., page 12, line 15 - page 13, line 8 of the specification). The method further 
comprises sending a second initial TCP state of the selected server computer to the first BTCP 
module (e.g., BTCP module 830 of Figure 8), such that the first BTCP module can calculate a 
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second TCP state for the selected server computer in the TCP/IP communication session. The 
method further comprises fonvarding data packets received at the first BTCP module from the 
client to the selected server computer, by changing the data packets to reflect the second TCP 
state and a second IP address of the selected sen,'er computer (e.g., block 1320 of Figure 13, and 
see page 12, line 1 5 - page 13, line 8 of the specification). The method further comprises 
sending response packets from the selected ser\'er computer directly to the client computer (see 
Figures 3 and 4) by changing the response packets to reflect the first TCP state and a first IP 
address of the first server computer (e.g., block 1440 of Figure 14, and see page 12, line 15- page 
1 3, line 8 of the specification). And, the method further comprises tenninating the TCP/IP 
communication session at the first server computer when the TCP/IP communication session is 
closed (e.g., page 13, lines 10-19). 

According to another claimed embodiment, such as that of independent claim 26, a server 
computer comprises an upper TCP (UTCP) module (e.g., UTCP module 522 of Figure 5C, and 
UTCP modules 810 and 850 of Figure 8) located above a TCP module (e.g., TCP module 520 of 
Figures 5B and 5C, and TCP modules 820 and 860 in Figure 8) in an operating system of the 
server computer. The sei-ver computer further comprises a bottom TCP (BTCP) module (e.g., 
BTCP module 524 of Figure 5C, and BTCP modules 830 and 870 of Figure 8) located below the 
TCP module. The UTCP, TCP, and BTCP modules implement a method of handing off a 
communication session between a first node (e.g., server 450 of Figure 4, and "front-end" node 
of Figure 8) and second node (e.g., server 452 of Figure 4, and "back-end" node of Figure 8) in a 
cluster network (e.g., cluster 490 of Figure 4) that works within the kernel level of an existing 
TCP/IP protocol, by migrating TCP states associated with the first and second nodes (see page 
10, line 26 - page 12, line 13 of the specification). 
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VL GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 1-37 are rejected under 35 U.S.C. § 1 03(a} as being unpatentable over U.S. Patent 
No. 6,775,692 issued to Albert et al (hereinafter ''Albei-r) in view of U.S. Patent No. 5,774,660 
issued to Brendel et al. (hereinafter "Brendel"). 

VII. ARGUMENT 

Appellant respectfully traverses the outstanding rejections of the pending claims, and 
requests that the Board reverse the outstanding rejections in light of the remarks contained 
herein. Below, Appellant argues many of the rejected claims separately. Thus, Appellant 
respectfully asserts that separately argued claims do not stand or fall together, see 37 C.F.R. § 
41.37(c)(i)(vii). 

All of claims 1-37 were previously rejected in a Final Office Action mailed April 20, 
2005 as being anticipated under 35 U.S.C. § 102(e) hy Albert. In response. Applicant appealed 
the rejection to the Board and submitted an Appeal Brief presenting arguments regarding why 
the claims are not anticipated by Albert. In response to the Appeal Brief, the Examiner has 
reopened prosecution and now rejects the claims as being unpatentable ovqx Albert in view of 
Brendel. 

Appellant respectfully submits that Brendel does not cure the deficiencies of Albert for 
the reasons discussed below. In particular, Brendel is discussed in the Background section of the 
present application {see page 5, line 25 - page 6, line 12 of the present application) and is noted 
as disclosing an inefficient mechanism for transfeixing TCP states that requires use of a 
proprietary protocol that is known only to the application level, which embodiments of the 
present invention overcome. Thus, for the reasons discussed further below, the combination of 
Brendel with Albert fails to render the claims unpatentable. As such. Appellant respectfully 
requests that the rejections be overturned and this application be passed to allowance. 

The test for non-obvious subject matter is whether the differences between the subject 
matter and the prior art are such that the claimed subject matter as a whole would have been 
obvious to a person having ordinary skill in the art to which the subject matter pertains. The 
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United States Supreme Court in Graham v. John Deere and Co., 383 U.S. 1 (1966) set forth the 
factual inquiries which must be considered in applying the statutory test: (1) determining of the 
scope and content of the prior art; (2) ascertaining the differences between the prior art and the 
claims at issue; and (3) resolving the level of ordinary skill in the pertinent art. As discussed 
further hereafter, Applicant respectfully asserts that the claims include non-obvious differences 
over the cited art. 

As discussed further below, when considering the scope and content of the applied Albert 
and Brendel references there are significant differences between the applied combination and the 
claims, as the applied combination fails to disclose all elements of the claims. Thus, considering 
the lack of disclosure in the applied combination of all elements of the claims, one of ordinary 
skill in the art would not find the claims obvious under 35 U.S.C. §103, and therefore the 
rejections should be overturned. 

Independent Claim 1 

Independent claim 1 recites: 

In a communication network, a method of TCP state migration comprising 
the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and a first server computer, said first server computer part of a plurality 
of server computers forming a web cluster containing infomiation, said 
communication session established for the transfer of data contained within said 
information; 

b) handing off said communication session to a selected server 
computer from said first server computer over a persistent control channel using 
TCP handoff modules that are dynamically loadable within TCP/IP stacks in 
operating systems located at both said first server computer and said selected 
server computer, that implement a TCP handoff protocol that works ^vithin kernel 
levels of an existing TCP/IP protocol ; and 

c) migrating a first TCP state of said first server computer to said 
selected server computer, and a second TCP slate of said selected server computer 
to said first sers^er computer over said control channel. (Emphasis added). 

The combination of. Albert and Brendel fails to teach or suggest all elements of 



independent claim 1. For the reasons discussed at length in the Appeal Brief of January 5, 2006, 
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Albert fails to disclose at least: 

A) TCP handoff modules that are dynamically loadable witliin TCP/IP stacks in operating 
systems located at both said first server computer and said selected ser\'er computer; 

B) handing off said communication session; and 

C) a persistent control channel. 

The Final Office Action appears to concede that Albert fails to teach or suggest "b) 
handing off said communication session to a selected server computer from said first server 
computer over a persistent control channel using TCP handoff modules that are dynamically 
loadable within TCP/IP stacks in operating systems located at both said first server computer and 
said selected ser\'er computer, that implement a TCP handoff protocol that works within kernel 
levels of an existing TCP/IP protocol", see page 3 of the Final Office Action. Hov^fever, the 
Final Office Action asserts that Brendel discloses this element of the claim. Appellant 
respectftilly disagrees, as discussed below. 

The present application briefly discusses Brendel at page 5, line 25 - page 6, line 12 as 
follows: 

Previously, various mechanisms for transferring TCP states were 
implemented, including using a separate proprietaiy protocol at the application 
layer of an operating system. For example, in the Brendel et al. patent (U.S. 
5,774,660), incoming packets to tlie front-end node have their protocol changed 
from TCP/IP protocol to a non-TCP/IP standard that is only understood by the 
proprietary protocol located at the application layer. Later, the packets are 
changed back to the TCP/IP protocol for transmission to the back-end web server. 
Thus, the Brendel et aL patent reduces processing efficiency by switching back 
and forth between the user-level and kernel level layers of the operating system. 

Thus, a need exists for a more efficient design for implementing a 
mechanism for transferring TCP states in a web server cluster. 

Thus, the present application expressly recognized that Brendel fails to provide TCP 
handoff modules within TCP/IP stacks in operating systems that implement a TCP handoff 
protocol that works within kernel levels of an existing TCP/IP protocol. Instead, Brendel 
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requires that incoming packets be changed into a proprietary protocol that is understood only at 
the application layer. For instance, Brendel explains at col. 13, lines 40-46 thereof: 

Modified TCP/IP stack 82 contains the standard TCP and IP modules with 
some modifications explained later. One modification is that incoming packets 
from the Internet have their protocol changed from TCP to a proprietary "IXP" 
protocol Since this IXP protocol is unknown to the standard TCP and IP layers, 
it is sent directly up to application layer 80 containing the load balancer. 

Thus. Brendel appears to disclose a system in which the TCP/IF stack of an operating 
system is modified so as to chrnige incoming packets from the TCP protocol to a proprietary 
protocol that is understood only at the application layer, rather than implementing TCP handoff 
modules within the TCP/IP stack to implement a TCP handoff protocol as recited by claim 1 . 

Thus, for at least the above reasons, the combination of Albert and Brendel fails to 
disclose all elements of claim 1 . As such, the rejection of claim 1 should be overturned, and 
claim 1 should be passed to allowance. 
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Independent Claim 11 

Independent claim 1 1 recites: 

In a communication network, a method of TCP state migration comprising 
tlie steps of: 

a) establishing a TCP/IP communication session between a client 
computer and a first server computer, said first server computer part of a plurality 
of sen,fer computers forming a web cluster containing information, said 
communication session established for the transfer of data contained witliin said 
information; 

b) monitoring traffic associated with establishing said TCP/IP 
communication session to understand a first initial TCP state of said first server 
computer associated with said TCP/IP communication session, at a first bottom- 
TCP (BTCP) module at said first server computer; 

c) receiving a web request associated with said TCP/IP 
communication session at said first BTCP module at said first server computer; 

d) examining content of said web request; 

e) determining which of said plurahty of server computers, a selected 
server computer, can best process said web request, based on said content; 

f) handing off said communication session to said selected server 
computer from said first sei-ver computer over a persistent control channel, if said 
selected server computer is not said first server computer; 

g) monitoring traffic associated with handing off said TCP/IF 
communication session to understand a second initial TCP state of said selected 
server computer associated with said TCP/IP communication session, at a second 
BTCP module at said selected server computer; 

h) migrating said first initial TCP state to said selected server 
computer over said control channel, such that said second BTCP module can 
calculate a first TCP state for said first server computer in said TCP/IP 
communication session; 

i) sending a second initial TCP state of said selected server computer 
to said first BTCP module, such that said first BTCP module can calculate a 
second TCP state for said selected serv^er computer in said TCP/IP 
communication session; 

j) forwarding data packets received at said first BTCP module from 
said client to said selected server computer, by changing said data packets to 
reflect said second TCP state and a second IP address of said selected server 
computer; 

k) sending response packets firom said selected server computer 
directly to said client computer by changing said response packets to reflect said 
first TCP state and a first IP address of said first server computer; and 
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1) terminating said TCP/IP commimication session at said first server 
computer when said TCP/IP communication session is closed. 

The combination of Albert and Brendel fails to teach or suggest ail elements of 
independent claim 1 1 . As discussed further in tlie Appeal Brief of January 5, 2006, Albert fails 
to disclose at least: 

A) a first bottom-TCP (BTCP) module at said first server computer, and a second BTCP 
module at said selected server computer; 

B) examining content of said web request and determining which of said plurality of 
server computers, a selected server computer, can best process said web request, based on said 
content; 

C) sending response packets from said selected server computer directly to said client 
computer; 

D) handing off said communication session; and 

E) a persistent control channel. 

Further, Brendel fails to teach or suggest at least a first bottom-TCP (BTCP) module at 
said first server computer, and a second BTCP module at said selected server computer, as 
recited by claim 11, For instance, as discussed above with claim 1, Brendel does not teach or 
suggest any such BTCP modules, but instead appears to disclose a modified TCP/IP stack that 
changes an incoming packet's protocol to a proprietary protocol that is unknown to the TCP/IP 
stack for handling at the application level. 

Thus, for at least the above reasons, the combination of Albert and Brendel fails to 
disclose all elements of claim 11. As such, the rejection of claim 1 1 should be overturned, and 
claim 1 1 should be passed to allowance. 
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liniependent Claim 26 

Independent claim 26 recites: 

A server computer comprising: 

an upper TCP (UTCP) module located above a TCP module in an 
operating system of said server computer; 

a bottom TCP (BTCP) module located below said TCP module, said 
UTCP, TCP, and BTCP modules implementing a method of handing otTa 
communication session between a first node and second node in a cluster network 
that works within the kernel level of an existing TCP/IP protocol, by migrating 
TCP states associated with said first and second nodes. 

The combination of Albert and Brendel fails to teach or suggest all elements of 
independent claim 26. As discussed fuither in the Appeal Brief of January 5, 2006, Albert fails 
to disclose the recited UTCP and BTCP modules. 

Further, Brendel fails to disclose the UTCP and BTCP modules. For example, Brendel 
does not disclose UTCP, TCP, and BTCP modules that implement a method of handing off a 
communication session between a first node and second node in a cluster network that works 
within the kernel level of an existing TCP/IP protocol as recited by claim 26. For instance, as 
discussed above with claim 1, Brendel does not disclose any such modules that implement 
handing off a communication session that works witliin the kernel level of an existing TCP/IP 
protocol, but instead appears to disclose a modified TCP/IP stack that changes an incoming 
packet's protocol to a proprietary protocol that is unknown to the TCP/IP stack for handling at 
the application level 

Thus, for at least the above reasons, the combination of Albert and Brendel tails to 
disclose all elements of claim 26. As such, the rejection of claim 26 should be overturned, and 
claim 26 should be passed to allowance. 



25806400. i 



15 



Application No.: 09/880,631 



DocketNo.: 10010812-1 



Depemdeflt Claim 2 

Claim 2 depends from claim 1 and thus inherits all elements of claim 1 . Accordingly, 
claim 2 is allowable over the combination of Albert in view of Brendel at least for tlie reasons 
discussed above with claim 1. Additionally, claim 2 ftirther recites: 

The method as described in Claim 1, wherein said step a) comprises the 
steps of: 

receiving a SYN packet from said client at a first BTCP module located at 
said first ser\fer computer; 

sending said SYN packet upstream to a first TCP module located above 
said first BTCP module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP stale from said first SYN/ACK packet, 
including a first initial sequence number for said first TCP module associated with 
said TCP/IP communication session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 

receiving a web request packet associated with said TCP/IP 
communication session at said first BTCP module at said first server computer; 

storing said SYN, ACK and said web request packet at said first server 
computer. 

The combination of Albert in view of Brendel fails to disclose all of the frirther elements 
of claim 2. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 2 (see pages 4-5 of the Final Office Action), as the reasoning for rejecting claim 2 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 2 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 2. For 
instance, Albert fails to disclose at least the recited first BTCP module located at said first server 
computer. Further, Brendel does not appear to be relied upon in the rejection of claim 2 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 2 be overturned. 
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Dependent Claim 3 

Claim 3 depends from claim 2, which depends from claim 1 , and thus claim 3 inherits ail 
elements of claims 1 and 2. Accordingly, claim 3 is allowable ovsv Albert in view of Brendel at 
least for the reasons discussed above with claims 1 and 2. Additionally, claim 3 fiirther recites: 

The method as described in Claim 2, wherein said step b) comprises the 
steps of: 

examining content of said web request packet : 

detennining which of said plurality of server computers, a selected server 
computer^ can best process said WEB request packet, based on said content ; 

sending a handoff request from said first BTCP module to a second BTCP 
module at said selected server computer over said control channel, if said selected 
ser\fer computer is not said first server computer; 

including said SYN packet and said ACK packet in said handoff request 

packet; 

changing a first destination IP address of said SYN packet to a second IP 
address of said selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, 
including a second initial sequence number, for said second TCP module, that is 
associated with said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second IP address, at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected 
server computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; and 

sending a handoff acknowledgment message to said first BTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 3. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 3 {see pages 5-6 of the Final Office Action), as the reasoning for rejecting claim 3 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 3 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 3. For 
instance, Albert fails to teach at least the recited second BTCP module at said selected server 
computer. Further, as discussed below with independent claim 1 \^ Albert fails to teach 
examining content of said web request packet and determining which of said plurality of sers'er 
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computers, a selected server computer, can best process said WEB request packet, based on said 
content . Furtlier, Brendel does not appear to be relied upon in tlie rejection of claim 3 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 3 be overturned. 

Dependent Claim 4 

Claim 4 depends from claim 3, which depends from claim 2 which depends from 1, and 
thus claim 4 inherits all elements of claims 1, 2, and 3. Accordingly, claim 4 is allowable over 
Albert in view of Brendel at least for the reasons discussed above with claims 1-3. Additionally, 
claim 4 further recites: 

The method as described in Claim 3, wherein step c) comprises the steps 

of: 

monitoring traffic associated with establishing said TCP/IP 
communication session in step a), at said first BTCP module, to parse a first initial 
TCP state of said first server computer, said first initial TCP state associated with 
said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over 
said control channel by including said first initial TCP state in said haiidoff 
request packet, said first initial TCP state including a first sequence number, such 
that said second BTCP module can calculate said first TCP state for said first 
server computer in said TCP/IP communication session. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 4. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 4 (see pages 6-7 of the Final Office Action), as the reasoning for rejecting claim 4 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 4 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 4. For 
instance, Albert fails to teach at least the recited "migrating said first initial TCP state to said 
second BTCP module over said control channel by including said first initial TCP state in said 
handoff request packet, said first initial TCP state including a first sequence number". Further, 
Brendel does not appear to be relied upon in the rejection of claim 4 as disclosing these elements, 
nor does it do so. 
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Accordingly, Appellant respectfully requests that the rejection of claim 4 be overturned. 
Dependent Claim 5 

Claim 5 depends from claim 3, which depends from claim 2 which depends from 1, and 
thus claim 5 inlierits all elements of claims 1, 2, and 3. Accordingly, claim 5 is allowable over 
Albert in view of Brendel at least for the reasons discussed above with claims 1-3. Additionally, 
claim 5 further recites: 

The method as described in Claim 3, wherein step c) comprises the steps 

of: 

monitoring traffic associated with handing off said TCP/IP communication 
session at said second BTCP module, to parse a second initial TCP state of said 
selected server computer, said second initial TCP state associated with said 
TCP/IP communication session; and 

migrating said second initial TCP state of said selected server computer to 
said first BTCP module by including said second initial TCP state in said handoff 
acknowledgment packet, said second initial TCP state including a second initial 
sequence number, such that said first BTCP module can calculate said second 
TCP state for said selected server computer in said TCP/IP communication 
session. 

The combination oi Albert in view of Brendel fails to disclose all of the further elements 
of claim 5. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 5 {see page 7 of the Final Office Action), as the reasoning for rejecting claim 5 appears to 
be the same as in the Final Office Action of April 20, 2005 (in which claim 5 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 5. For 
instance, Albert fails to teach at least the recited "migrating said second initial TCP state of said 
selected server computer to said first BTCP module by including said second initial TCP state in 
said handoff acknowledgment packet, said second initial TCP state including a second initial 
sequence number". Further, Brendel does not appear to be relied upon in the rejection of claim 5 
as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 5 be overturned. 
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Claim 6 depends from claim 2, which depends from claim 1, and thus claim 6 inherits all 
elements of claims I and 2. Accordingly, claim 6 is allowable ovqv Albert in view of Brendel at 
least for the reasons discussed above with claims 1 and 2. Additionally, claim 6 further recites: 

The method as described in Claim 2, comprising the further steps of; 

intercepting a connection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper-TCP 
(UTCP) module, said connection indication message sent by said first TCP 
module upon establishing said communication session; and 

holding said connection indication message at said first UTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the fiirther elements 
of claim 6. The Final Office Action appears to rely u^on Albert as disclosing all elements of 
claim 6 {see pages 7-8 of the Final Office Action), as the reasoning for rejecting claim 6 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 6 was rejected as 
being anticipated by Albert), However, Albert fails to disclose all elements of claim 6. For 
instance, Albert fails to teach at least the recited first upper TCP UTCP) module. Further, 
Brendel does not appear to be relied upon in the rejection of claim 6 as disclosing these elements, 
nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 6 be overturned. 
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Dependent Claim 7 

Claim 7 depends from claim 6, which depends from claim 2 which depends from claim 1, 
and thus claim 7 inherits all elements of claims 1 , 2, and 6. Accordingly, claim 7 is allowable 
o\Qv Albert in view of Brendel at least for the reasons discussed above with claims 1, 2, and 6. 
Additionally, claim 7 further recites: 

The method as described in Claim 6, wherein said method comprises the 
ftirther steps of: 

sending a reset packet from said first BTCP module upon receiving said 
handoff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 
receiving incoming data packets from said client at said first BTCP 

module; 

changing said destination addresses of said incoming data packets to said 
second IP address; 

updating sequence numbers and TCP checksum in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 7. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 7 {see pages 8-9 of the Final Office Action), as tlie reasoning for rejecting claim 7 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 7 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 7. For 
instance, Albert fails to teach at least the recited "sending a reset packet from said first BTCP 
module upon recei ving said handoff acknowledgment packet to said first TCP module". Further, 
Brendel does not appear to be relied upon in the rejection of claim 7 as disclosing these elements, 
nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 7 be overturned. 
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Dependent Claim 8 

Claim 8 depends from claim 6, which depends from claim 2 which depends from claim 1, 
and thus claim 8 inherits all elements of claims 1 , 2, and 6. Accordingly, claim 8 is allowable 
over Albert in view of Brendel at least for the reasons discussed above with claims 1, 2, and 6. 
Additionally, claim 8 further recites: 

The method as described in Claim 6, comprising the further steps of: 
sending notification from said first BTCP module to said firet UTCP 

module to release said connection indication message, if said selected server 

computer is said first server computer; 

sending incoming data packets, including said web request packet, from 

said client, received at said first BTCP module, upstream. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 8. The Final Office Action appears to rely \x^oxi Albert as disclosing all elements of 
claim 8 {see page 9 of the Final Office Action), as the reasoning for rejecting claim 8 appears to 
be the same as in the Final Office Action of April 20, 2005 (in which claim 8 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 8. For 
instance, Albert fails to teach at least the recited "sending notification from said first ETC? 
module to said first UTCP module to release said comiection indication message, if said selected 
server computer is said first server computer". Further, Brendel does not appear to be relied 
upon in the rejection of claim 8 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 8 be overturned. 
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De pendent Claim 9 

Claim 9 depends from claim 1 and thus inlierits all elements of claim 1. Accordingly, 
claim 9 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 1, Additionally, claim 9 further recites: 

The method as described in Claim 1, comprising the further step of: 

intercepting outgoing response packets from said selected server computer 
at a second bottom TCP (BTCP) module located at said selected server computer; 

changing source addresses of said response packets to a first IP address of 
said first ser\?er computer; 

updating sequence numbers and TCP checksum in said response packets 
to reflect said first TCP state of said first sei-ver computer; and 

sending said response packets to said client. 

The combination of Albert in view of Brendel fails to disclose all of the furtlier elements 
of claim 9. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 9 {see pages 9-10 of the Final Office Action), as the reasoning for rejecting claim 9 
appeai-s to be the same as in the Final Office Action of April 20, 2005 (in which claim 9 was 
rejected as being anticipated by Albert). However, Albert fails to disclose all elements of claim 
9. For instance, Albert fails to teach at least the recited second bottom TCP (BTCP) module 
located at said selected server computer. Further, Brendel does not appear to be relied upon in 
the rejection of claim 9 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 9 be overturned. 
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De pendent Claim 10 

Claim 10 depends from claim i and thus inherits all elements of claim 1. Accordingly, 
claim 10 is allowable over Alberl in view of Brendel at least for the reasons discussed above with 
claim L Additionally, claim 10 further recites: 

The method as described in Claim 1, comprising the flirther steps of: 
monitoring TCP/IP control traffic for said communication session at said 

second BTCP module; 

understanding when said communication session is closed at said second 

server computer; 

sending a teiiuination message to said first server computer over said 
control channel; 

terminating said TCP/IP communication session at said first server 
computer by terminating a forwarding mode at said first BTCP module; and 

freeing data resources associated with said communication session at said 
first server computer. 

The combination Qf Albert in view of Brendel fails to disclose all of the further elements 
of claim 10. The Final Office Acfion appears to rely upon Albert as disclosing all elements of 
claim 10 {see page 10 of the Final Office Action), as tlie reasoning for rejecting claim 10 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 10 was rejected as 
being anticipated by Albert), Howqvqv, Albert fails to disclose all elements of claim 10. For 
instance, Albert fails to teach at least the recited first and second bottom TCP (BTCP) modules. 
Further, Brendel does not appear to be relied upon in the rejection of claim 10 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectflilly requests that the rejection of claim 10 be overturned. 
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Dependent Claim 12 

Claim 12 depends from claim 1 1 and thus inherits all elements of claim 1 1. Accordingly, 
claim 12 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 11, Additionally, claim 12 fiirther recites: 

The method as described in Claim 11, wherein said step a) comprises the 
steps of: 

receiving a packet from said client at said first BTCP module; 

sending said SYN packet upsti'eam to a first TCP module located above 
said first BTCP module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state from said first SYN/ACK packet, 
including a first initial sequence number for said first TCP module associated 
with, said TCP/IP communication session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 

storing said SYN, ACK and said web request at said first sei-ver computer. 

The combination of Albert in view of. Brendel fails to disclose all of the further elements 
of claim 12. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 12, as the reasoning for rejecting claim !2 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 12 was rejected as being anticipated hy Albert). 
However, Albert fails to disclose all elements of claim 12. For instance, Albert fails to teach at 
least the recited "sending said SYN packet upstream to a first TCP module located above said 
first BTCP module in a first operating system of said first server computer". Further, Brendel 
does not appear to be relied upon in the rejection of claim 12 as disclosing these elements, nor 



Accordingly, Appellant respectfully requests that the rejection of claim 12 be overturned. 
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Dependent Claim 13 

Claim 13 depends from claim 1 1 and thus inherits all elements of claim 1 1 . Accordingly, 
claim 13 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim II. Additionally, claim 13 further recites: 

The method as described in Claim 11, wherein said step e) comprises the 
steps of: 

sending a handoff request packet from said first BTCP module to said 
second BTCP module over said control channel; 

including said SYN packet and said ACK packet in said handoff request 

packet; 

changing a first destination IP address of said SYN packet to a second IP 
address of said selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, 
including a second initial sequence number, for said second TCP module, that is 
associated with said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second IP address, at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected 
ser\'er computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; and 

sending a handoff acknowledgment message to said first BTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 1 3, The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 13, as the reasoning for rejecting claim 13 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 13 was rejected as being anticipated hy Albert), 
However, Albert fails to disclose all elements of claim 13. For instance, Albert fails to teach at 
least the recited "changing a second destination IP address of said ACK packet to said second IP 
address, atsaid_sec ond BTCP module ; . . .and sending a handoff acknowledgment message to 
said first BTCP module " (emphasis added). Further, Brendel does not appear to be relied upon 
in the rejection of claim 13 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 13 be overturned. 
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Dependent Claims 14-15 

Claims 14-15 each depend from claim 13, which depends from claim 11, Thus, claims 
14 and 15 each inherit all elements of claims 1 1 and 13, and are therefore allowable over Albert 
in view of Brendel at least for the reasons discussed above with claims 1 1 and 13. Therefore, 
Appellant respectfiilly requests that the rejection of claims 14 and 15 be overturned. 

Dependent Ciaim 16 

Claim 16 depends from claim 13, which depends from claim 11, and thus claim 16 
inherits all elements of claims 1 1 and 13. Accordingly, claim 16 is allowable over Albert in view 
of Brendel at least for the reasons discussed above with claims 1 1 and 13. Additionally, claim 
16 further recites; 

The method as described in Claim 13, comprising the further steps of: 
intercepting a comiection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper-TCP 
(UTCP) module, said connection indication message sent by said first TCP 
module upon establishing said communication session; and 

holding said connection indication message at said first UTCP module. 

The combination of Albert, in view of Brendel fails to disclose all of the further elements 
of claim 1 6. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 16, as the reasoning for rejecting claim 16 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 16 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 16. For instance, Albert fails to teach at 
least the recited first upper TCP (UTCP) module. Further, Brendel does not appear to be relied 
upon in the rejection of claim 16 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 16 be overturned. 

Dependent Claim 17 
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Claim 17 depends from claim 16, which depends from claim 13 which depends from 
claim 1 1, and thus claim 17 inherits all elements of claims 11, 13, and 16. Accordingly, claim 17 
is allowable over Albert in view of Brendel at least for the reasons discussed above with claims 
11, 13, and 16. Additionally, claim 17 fxirther recites: 

The method as described in Claim 16, wherein step h) comprises tlie 
further steps of: 

sending a reset packet from said first BTCP module upon receiving said 
handoff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 
receiving incoming data packets from said client at said first BTCP 

module; 

changing said destination addresses of said incoming data packets to said 
second IP address; 

updating sequence numbers and TCP checksum in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 17. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 17, as the reasoning for rejecting claim 1 7 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 1? was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 17. For instance, Albert fails to teach at 
least the recited "sending a reset packet trom said first BTCP module upon receiving said 
handoff acknowledgment packet to said first TCP module". Further, Brendel does not appear to 
be relied upon in the rejection of claim 17 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 17 be overturned. 
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Dependent Claim 18 

Claim 18 depends from claim 1 1 aiid thus inherits all elements of claim 11. Accordingly, 
claim 18 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 1 1 . Additionally, claim 1 8 further recites: 

The method as described in Claim 1 1, wherein step k) comprises the steps 

of: 

intercepting outgoing response packets from said selected server computer 
at said second BTCP module; 

changing source addresses of said response packets to said first IP address; 

updating sequence numbers and TCP checksum in said response packets 
to reflect said first TCP state of said first server computer; and 

sending said updated response packets to said client. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 1 8. The Final Office Action appears to rely upon Albert as disclosing ail elements of 
claim 1 8, as the reasoning for rejecting claim 1 8 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 1 8 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 1 8. For instance, Albert fails to teach at 
least the recited "intercepting outgoing response packets from said selected server computer at 
said second BTCP module". Further, Brendel does not appear to be relied upon in the rejection 
of claim 1 8 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 18 be overturned. 
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Dependent Claim 19 

Claim 19 depends from claim 1 1 and thus inherits all elements of claim 11, Accordingly, 
claim 19 is allowable ovor Albert in view of Brendel at least for the reasons discussed above with 
claim 1 1. Additionally, claim 19 further recites: 

The method as described in Claim 11, wherein step 1) comprises the steps 

of: 

monitoring TCP/IP control traffic for said communication session at said 
second BTCP module; 

understanding when said communication session is closed at said second 
server computer; 

sending a termination message to said first server computer over said 

control channel; 

terminating a foi-warding mode at said first BTCP module; and 

freeing data resources associated with said communication session at said 

first server computer. 

The combination of Albert in view of Brendel fails to disclose all of the furdier elements 
of claim 19. The Final Office Action appears to rely \xpoxi Albert as disclosing all elements of 
claim 19, as the reasoning for rejecting claim 19 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 19 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 19. For instance, Albert fails to teach at 
least the recited "monitoring TCP/IP control traffic for said communication session at said 
second BTCP module" and "tenninating a forwarding mode at said first gxcP module". 
Further, Brendel does not appear to be relied upon in the rejection of claim 19 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 19 be overturned. 
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Dependent Claim 20 

Claim 20 depends from claim 1 6, which depends from claim 1 3 which depends from 
claim 11, and thus claim 20 inherits all elements of claims 11, 1.3, and 16. Accordingly, claim 20 
is allowable over Albert in view of Brendel at least for the reasons discussed above with claims 
1 1, 13, and 16. Additionally, claim 20 further recites: 

The method as described in Claim 16, comprising the furtlier steps of: 
sending notification from said first BTCP module to said first UTCP 

module to release said connection indication message, if said selected server 

computer is said first server computer; and 

sending incoming data packets, including said web request, from said 

client, received at said first BTCP module, upstream. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 20, ITie Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 20, as the reasoning for rejecting claim 20 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 20 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 20. For instance, Albert fails to teach at 
least the recited "sending notification from said first BTCP module to said first UTCP module to 
release said connection indication message, if said selected server computer is said first server 
computer". Further, Brendel does not appear to be relied upon in the rejection of claim 20 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfiilly requests that the rejection of claim 20 be overturned. 

Dependent Claim 21 

Claim 21 depends from claim 1 1 and thus inherits all elements of claim 1 1. Accordingly, 
claim 21 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 1 1 . Additionally, claim 21 further recites: 

The method as described in Claim 11, wherein each of said plurality of 
server computers is constructed sirailaily including BTCP modules located 
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downstream from TCP modules, and UTCP modules located upstream from TCP 
modules. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 2 1 . The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 21, as the reasoning for rejecting claim 21 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 21 was rejected as being anticipated by Albert). 
However, Albert fails to disclose ail elements of claim 21. For instance, ^/6e/Y fails to teach 
each of its server computers include BTCP modules located downstream from TCP modules, and 
UTCP modules located upstream from TCP modules. Again, Albert fails to teach the recited 
BTCP and UTCP modules. Further, Brendel does not appear to be relied upon in the rejection of 
claim 21 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respect&lly requests that the rejection of claim 21 be overturned. 

Pepcndent Ciaini 22 

Claim 22 depends from claim 12, which depends from claim 1 1 . Thus, claim 22 inherits 
all elements of claims 1 1 and 12, and are therefore allowable over Albert in view of Brendel at 
least for the reasons discussed above with claims 1 1 and 12. Therefore, Appellant respectfully 
requests that the rejection of claim 22 be overturned. 

Dependent Claim 23 

Claim 23 depends from claim 22, which depends from claim 12 which depends from 
claim 11. Thus, claim 23 inherits all elements of claims H, 12, and 22. Accordingly, claim 23 
is allowable over Albert in view of Brendel at least for the reasons discussed above with claims 
11, 12, and 22. Additionally, claim 23 ftirther recites: 

The method as described in Claim 22, wherein said control channel allows 
for communication between all UTCP modules. 
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The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 23. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 23, as the reasoning for rejecting claim 23 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 23 was rejected as being anticipated by Albert), 
However, Albert fails to disclose all elements of claim 23. For instance, Albert fails to teach 
each UTCP modules, and thus fails to teach a control chamie! that allows communication 
between ali of such UTCP modules. Further, Brendel does not appear to be relied upon in the 
rejection of claim 23 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 23 be overturned. 

Dependent Claims 24-25 

Claims 24-25 each depend from claim 1 1, and thus claims 24 and 25 each inherit ali 
elements of claim 1 1. Therefore, claims 24-25 are each allowable over Albert in view oi Brendel 
at least for the reasons discussed above with claim 11. As such, Appellant respectfully requests 
that the rejection of claims 24 and 25 be overturned. 

Dependent Claim 27 

Claim 27 depends from claim 26 and thus inlierits all elements of claim 26. Accordingly, 
claim 27 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 26. Additionally, claim 27 further recites: 

The server computer as described in Claim 26, wherein said method 
comprises the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and said server computer, said first node, said server computer part of a 
plurality of server computers forming said cluster network containing 
infomation, said communication session established for the transfer of data 
contained within said information; 

b) receiving a web request associated with said TCP/IP 
communication session at a first BTCP module at said server computer; 

c) examining content of said web request : 

d) determining which of said plurality of server computers, a selected 
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server computer, can best process said web request, based on said content ; 

e) handing off said communication session to said selected server 
computer from said server computer over a persistent control channel, if said 
selected server computer is not said sender computer; and 

f) migrating a first TCP state of said server computer to said selected 
server computer, and sending a second TCP state of said selected server computer 
to said server computer over said control channel. (Emphasis added). 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 27. The Final Office Action appears to rely wpon Albert as disclosing all elements of 
claim 27, as the reasoning for rejecting claim 27 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 27 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 27. For instance, as discussed above with 
claim 1 L Albert fails to teach determining which of the plurality of server computers, a selected 
server computer, can best process a web request, based on content of the web request. As also 
discussed above with claim W.Albert fails to teach handing of a communication session over a 
persistent control channel Further, Brendel does not appear to be relied upon in the rejection of 
claim 27 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 27 be overturned. 

Dependent Claim 28 

Claim 28 depends from claim. 27, which depends from, claim 26, and thus claim 28 
inherits all elements of claims 26 and 27. Accordingly, claim 28 is allowable over Albert in view 
of Brendel at least for the reasons discussed above with claims 26 and 27, Additionally, claim 
28 further recites: 

The server computer as described in Claim 27, wherein step a) of said 
method comprises the steps of: 

receiving a SYN packet from said client at said BTCP module; 

sending said SYN packet upstream to said TCP module; 

receiving a first SYN/ACK packet from said TCP module; 

parsing a first initial TCP state fi-om said first SYN/ACK packet, including 
a first initial sequence number for said TCP module associated with said TCP/IP 
communication session; 
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sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said BTCP module; 

sending said ACK packet to said TCP module; 

storing said SYN, ACK at said server computer. 

The combination of Albert in view ofBrendel fails to disclose all of the further elements 
of claim 28. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 28, as the reasoning for rejecting claim 28 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 28 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 28. For instance, as discussed above, 
Albert fails to teach the BTCP module, and thus for at least this mason Albert fails to teach the 
above steps that involve such BTCP module. Further, Brendel does not appear to be relied upon 
in tlie rejection of claim 28 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 28 be overturned. 

Dependent Claim 29 

Claim 29 depends from claim 28, which depends from claim 27 vMoh depends from 
claim 26, and thus claim 29 inherits all elements of claims 26-28. Accordingly, claim 29 is 
allowable over Albert in view of Brendel at least for the reasons discussed above with claims 26- 
28. Additionally, claim 29 lurther recites: 

The server computer as described in Claim 28, wherein said method 
comprises the steps of: 

sending a handoff request packet from said BTCP module to a second 
BTCP module over said control channel, said second BTCP module located 
below a second TCP module in a second operating system at said selected server 
computer; 

including said SYN packet and said ACK packet in said handoff request; 
receiving a handoff acknowledgment message at said BTCP module from 
said second BTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 29. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 29, as the reasoning for rejecting claim 29 appears to be the same as in the Final Office 
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Action of April 20, 2005 (in which claim 29 was rejected as being anticipated by Albert). 
However, Aibeti fails to disclose all elements of claim 29. For instance, as discussed above, 
Albert fails to teach the recited BTCP modules, and thus for at least this lea&on Albert fails to 
teach the above steps that involve such BTCP modules. Further, Brendel does not appear to be 
relied upon in the rejection of claim 29 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 29 be overturned. 

Dependent Claim 30 

Claim 30 depends from claim 29, which depends from claim 28 which depends from 
claim 27 which depends from claim 26, and thus claim 30 inlierits all elements of claims 26-29. 
Accordingly, claim 30 is allowable over Albert in view of Brendel at least for the reasons 
discussed above with claims 26-29, Additionally, claim 30 further recites; 

The server computer as described in Claim 29, wherein said step f) of said 
method comprises the steps of: 

monitoring traffic associated with establishing said TCP/IP 
communication session in step a), at said BTCP module, to parse a first initial 
TCP state of said server computer, said first initial TCP state associated with said 
TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over 
said control channel by including said first initial TCP state in said handoff 
request, said first initial TCP state including a first sequence number, such that 
said second BTCP module can calculate said first TCP state for said server 
computer in said TCP/IP communication session. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 30. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 30, as the reasoning for rejecting claim 30 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 30 was rejected as being anticipated hy Albert). 
However, Albert fails to disclose all elements of claim 30. For instance, as discussed above, 
Albert fails to teach the recited BTCP module and conh'ol channel, and thus for at least these 
reasons Albert fails to teach the above steps that involve such BTCP modules and control 
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channel. Further, Brendel does not appear to be relied upon in the rejection of claim 30 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 30 be overturned. 
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Dependent Ciaim 31 

Claim 3 1 depends from claim 29, which depends from claim 28 which depends from 
claim 27 which depends from claim 26, and thus claim 31 inherits all elements of claims 26-29. 
Accordingly, claim 31 is allowable oyer Albert in view of Brendel at least for the reasons 
discussed above with claims 26-29, Additionally, claim 3 1 further recites: 

The server computer as described in Claim 29, wherein said method 
comprises the furtlier steps of: 

intercepting a connection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper-TCP 
(UTCP) module, said connection indication message sent by said first TCP 
module upon establishing said communication session; and 

holding said comiection indication message at said first UTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the furtlier elements 
of claim 3 1 . The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 3 1, as the reasoning for rejecting claim 31 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 31 was rejected as being anticipated hy Albert). 
However, Albert fails to disclose all elements of claim 3 1 . For instance, Albert fails to teach the 
recited first upper TCP (UTCP) module, and thus for at least tliis reason Albert fails to teach the 
above steps that involve such UTCP module. Further, Brendel does not appear to be relied upon 
in the rejection of claim 31 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 31 be overturned. 
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Dependent Claim 32 

Claim 32 depends from claim 3 1 , which depends from claim 29 which depends from 
claim 28 which depends from claim 27 which depends from claim 26, and thus claim 32 inherits 
all elements of claims 26-29 and 31. Accordingly, claim 32 is allowable over Albert in view of 
Brendel at least for the reasons discussed above with claims 26-29 and 31 . Additionally, claim 
32 further recites: 

The computer system as described in Claim 31, wherein said method 
comprises the flirther steps of: 

sending a reset packet from, said first BTCP module upon receiving said 
handoff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 

receiving incoming data packets from said client at said first BTCP 
module; 

changing said destination addresses of said incoming data packets to said 
second IP address; 

updating sequence numbers and TCP checksum in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

The combination of Albert in view Brendel fails to disclose all of the further elements 
of claim 32, The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 32, as the reasoning for rejecting claim 32 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 32 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 32. For instance, Albert fails to teach the 
recited "sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module" and "discarding said connection indication 
message at said first UTCP module". Further, Brendel does not appear to be relied upon in the 
rejection of claim 32 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 32 be overturned. 
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Dependent Claim 33 

Claim 33 depends from claim 31, which depends from claim 29 which depends from 
claim 28 which depends from claim 27 which depends from claim 26, and thus claim 33 inherits 
all elements of claims 26-29 and 3 1 . Accordingly, claim 33 is allowable over Albert in view of 
Brendei at least for tlie reasons discussed above with claims 26-29 and 31. Additionally, claim 
33 ftirther recites: 

The sender computer as described in Claim 31, said method comprising the 
further steps of: 

sending notification from said BTCP module to said UTCP module to 
release said connection indication message, if said selected server computer is 
said server computer; 

sending incoming data packets, including said web request, from said 
client, received at said first BTCP module, upstream. 

The combination of Albert in view of Brendei fails to disclose all of the further elements 
of claim 33. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 33, as the reasoning for rejecting claim 33 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 33 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 33. For instance, Albert fails to teach the 
recited BTCP and UTCP modules, and thus for at least this reason Albert fails to teach the above 
steps involving such modules. Further, Brendei does not appear to be relied upon in the rejection 
of claim 33 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 33 be overturned. 
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Dependent Claim 34 

Claim 34 depends from claim 26, and thus inherits all elements of claim 26. 
Accordingly, claim 34 is allowable over Albert in view ofBrendel at least for the reasons 
discussed above with claim 26. Additionally, claim 34 further recites: 

The server computer as described in Claim 26, said method comprising the 
further steps of: 

receiving a handoff request from a first BTCP module located at a first 
sei-ver computer within said cluster network over a persistent control channel, said 
first server computer having established a communication session with a client 
computer, said communication session established for the transfer of data 
contained within said server computer, said handoff request including a SYN 
packet and an ACK packet, said SYN and ACK packet used for establishing said 
communication session between said client and said first server computer, said 
ACK packet including a first initial TCP state of said first server computer in said 
communication session, including a first initial TCP sequence number; 

changing a first destination IP address of said SYN packet to a second IP 
address of said server computer, at said BTCP module; 

sending said SYN packet to said TCP module; 

receiving a SYN/ ACK packet at said second BTCP module; 

parsing a second initial TCP state from second SYN/ACK packet, 
including a second initial sequence number, for said TCP module, said second 
initial TCP state associated with a second TCP state for said server computer in 
said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second IP address, at said BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected 
server computer in said communication session; 

sending said ACK packet that is updated to said TCP module; and 

sending a handoff acknowledgment message to said first BTCP module 
over said control chamiel. 

The combination oi Albert in view of Brendel fails to disclose all of the further elements 
of claim 34. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 34, as the reasoning for rejecting claim 34 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 34 was rejected as being anticipated by Albert). 
However, A lbert feils to disclose all elements of claim 34. For instance, Albert fails to teach at 
least the recited "receiving a handoff request fi-om a first BTCP module located at a first server 
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computer within said cluster network over a persistent control channel". As discussed above 
with claim l\, Albert fails to teach a first BTCP module or a persistent control channel. Further, 
Albert fails to teach a "handoff request". Rather, Albert merely teaches that its forwarding 
agents forward packets to a selected back-end server, rather than handing off the TCP 
communication session. Furtiier, Brendel does not appear to be rehed upon in the rejection of 
claim 34 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfiilly requests that the rejection of claim 34 be overturned. 

Dependent Claim 35 

Claim 35 depends from claim 34, which depends from claim 26, and thus claim 35 
inherits all elements of claims 26 and 34. Accordingly, claim 35 is allowable over Albert in view 
of Brendel at least for the reasons discussed above with claims 26 and 34. Additionally, claim 
35 further recites: 

The sei-ver computer as described in Claim 34, wherein said method 
comprises the forther steps of: 

monitoring traffic associated with handing off said TCP/IP communication 
session to said server computer, at said BTCP module, to parse said second initial 
TCP state of said server computer, said second initial TCP state associated with 
said TCP/IP communication session; and 

sending said second initial TCP state of said server computer to said first 
BTCP module by including said second initial TCP state in said handoff 
acknowledgment, said second initial TCP state including a second initial sequence 
number, such that said first BTCP module can calculate said second TCP state for 
said server computer in said TCP/IP communication session. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 35. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 35, as the reasoning for rejecting claim 35 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 35 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 35. For instance, Albert fails to teach at 
least the recited BTCP module, thus for at least this reason Albert fails to teach the above steps 
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that involve such BTCP module. Further , Brendel does not appear to be relied upon in the 
rejection of claim 35 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 35 be overtumed. 

Dependent Claim 36 

Claim 36 depends from claim 34, which depends from claim 26, and thus claim 36 
inherits all elements of claims 26 and 34. Accordingly, claim 36 is allowable ovqx Albert in view 
of Brendel at least for the reasons discussed above with claims 26 and 34. Additionally, claim 
36 further recites: 

The server computer as described in Claim 34, wherein said method 
comprises the further steps of: 

intercepting outgoing response packets from said server computer at said 
second BTCP module; 

changing source addresses of said response packets to said first IP address; 

updating sequence numbers and TCP checksum in said response packets 
to reflect said first TCP state of said first server computer; and 

sending said response packets to said client. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 36, The Final Office Action appears to rely upon J/^er/ as disclosing all elements of 
claim 36, as the reasoning for rejecting claim 36 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 36 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 36. For instance, Albert fails to teach at 
least the recited second BTCP module, thus for at least this reason Albert fails to teach the above 
intercepting step that involves such second BTCP module. Further, Brendel does not appear to 
be relied upon in the rejection of claim 36 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 36 be overturned. 
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Dependent Claim 37 

Claim 37 depends fi-om claim 34, which depends from claim 26, and thus claim 37 
inherits all elements of claims 26 and 34. Accordingly, claim 37 is allowable oyqi Albert in view 
of Brendel at least for the reasons discussed above with claims 26 and 34. Additionally, claim 
37 further recites; 

The server computer as described in Claim 34, wherein said method 
comprises the ftirther steps of: 

monitoring TCP/IP control traffic for said communication session at said 
BTCP module; 

understanding when said communication session is closed at said server 
computer; and 

sending a termination message to said first server computer over said 
control channel. 

The combination of Albert in view of Brendel fails to disclose all of the flirther elements 
of claim 37. The Final Office Action appears to rely wpon Albert as disclosing all elements of 
claim 37, as the reasoning for rejecting claim 37 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 37 was rejected as being anticipated by Albert). 
Hovv^ever, Albert fails to disclose ail elements of claim 37. For instance, Albert fails to teach at 
least the recited BTCP module and conti-oi channel, and thus fails to teach the above steps that 
involve such BTCP module and control channel. Further, Brendel does not appear to be relied 
upon in tlie rejection of claim 37 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 37 be overturned. 
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CONCLUSION 

In view of the above. Appellant requests that the board overturn the outstanding 
rejections of claims 1-37. Attached hereto are a Claims Appendix, Evidence Appendix, and 
Related Proceedings Appendix. As noted in the attached Evidence Appendix, no evidence 
pursuant to §§ 1.130, 1.131, or 1.132 or entered by or relied upon by the examiner is being 
submitted. Also, as noted by the Related Proceedings Appendix, no related proceedings are 
referenced in II above, and thus no copies of decisions in related proceedings are provided. 
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APPENDIX A 

Claims Involved in the Appeal of Application Serial No. 09/880,63 1 

1 . In a communication network, a method of TCP state migration comprising the 
steps of: 

a) establishing a TCP/IP communication session between a client computer and a 
first server computer, said first server computer part of a plurality of server computers forming a 
web cluster containing information, said communication session established for the transfer of 
data contained within said information; 

b) handing off said communication session to a selected server computer from said 
first server computer over a persistent control channel using TCP handoff modules that are 
dynamically loadable within TCP/IP stacks in operating systems located at both said first server 
computer and said selected server computer, that implement a TCP handoff protocol that works 
within kernel levels of an existing TCP/IP protocol; and 

c) migrating a first TCP state of said first server computer to said selected server 
computer, and a second TCP state of said selected server computer to said first server computer 
over said control channel. 

2. The method as described in Claim 1, wherein said step a) comprises the steps of: 
receiving a SYN packet from said client at a first BTCP module located at said first 

server computer; 

sending said SYN packet upstream to a first TCP module located above said first BTCP 
module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state from said first SYN/ACK packet, including a first 
initial sequence number for said first TCP module associated with said TCP/IP communication 
session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet fi:om said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 
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receiving a web request packet associated with said TCP/IP communication session at 
said first BTCP module at said first server computer; 

storing said SYN, ACK and said web request packet at said first server computer. 

3. The method as described in Claim 2, wherein said step b) comprises tlie steps of: 
examining content of said web request packet; 

detenuining which of said plurality of server computers, a selected server computer, can 
best process said WEB request packet, based on said content; 

sending a handoff request from said first BTCP module to a second BTCP module at said 
selected server computer over said control channel, if said selected server computer is not said 
first sender computer; 

including said SYN packet and said ACK packet in said handoff request packet; 

changing a first destination IP address of said SYN packet to a second IP address of said 
selected sei^ver computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, including a 
second initial sequence number, for said second TCP module, that is associated with said TCP/IP 
communication session; 

changing a second destination IP address of said ACK packet to said second IP address, 
at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; and 

sending a handoff acknowledgment message to said first BTCP module. 

4. The method as described in Claim 3, wherein step c) comprises the steps of: 
monitoring traffic associated with establishing said TCP/IP communication session in 

step a), at said first BTCP module, to parse a first initial TCP state of said first server computer, 
said first initial TCP state associated with said TCP/IP communication session; and 

migrating said first inifial TCP state to said second BTCP module over said control 
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channel by including said first initial TCP state in said handoff request packet, said first initial 
TCP state including a first sequence number, such that said second BTCP module can calculate 
said first TCP state for said first server computer in said TCP/IP communication session. 

5. The method as described in Claim 3, wherein step c) comprises the steps of: 
monitoring traffic associated with handing off said TCP/IP communication session at said 

second BTCP module, to parse a second initial TCP state of said selected server computer, said 
second initial TCP state associated with said TCP/IP communication session; and 

migrating said second initial TCP state of said selected server computer to said first 
BTCP module by including said second initial TCP state in said handoff acknowledgment 
packet, said second initial TCP state including a second initial sequence number, such that said 
first BTCP module can calculate said second TCP state for said selected server computer in said 
TCP/IP communication session. 

6. The method as described in Claim. 2, comprising the further steps of; 
intercepting a connection indication message sent from said first TCP module to an 

application layer above said first TCP module at a first upper-TCP (UTCP) module, said 
connection indication message sent by said first TCP module upon establishing said 
communication session; and 

holding said connection indication message at said first UTCP module. 

7. The method as described in Claim 6, wherein said method comprises the further 
steps of; 

sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 

receiving incoming data packets from said client at said first BTCP module; 

changing said destination addresses of said incoming data packets to said second IP 
address; 

updating sequence numbers and TCP checksum in said data packets to reflect said second 
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TCP state of said selected sender computer; and 

forwarding said data packets to said selected server computer. 

8. The method as described in Claim 6, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP module to release 

said connection indication message, if said selected server computer is said first ser%'er computer; 

sending incoming data packets, including said web request packet, from said client, 
received at said first BTCP module, upstream. 

9. The method as described in Claim 1 , comprising the further step of: 
intercepting outgoing response packets from said selected server computer at a second 

bottom TCP (BTCP) module located at said selected serv^er computer; 

changing source addresses of said response packets to a first IP address of said first 
server computer; 

updating sequence numbers and TCP checksum in said response packets to reflect said 
first TCP state of said first server computer; and 

sending said response packets to said client. 

10. The method as described in Claim 1 , comprising the further steps of: 
monitoring TCP/IP control traffic for said communication session at said second BTCP 

module; 

understanding when said communication session is closed at said second server 
computer; 

sending a termination message to said first server computer over said control channel; 

temiinating said TCP/IP communication session at said first server computer by 
terminating a forwarding mode at said first BTCP module; and 

freeing data resources associated with said communication session at said first server 
computer. 

11. In a commun ication network, a method of TCP state migration comprising the 
steps of: 

a) establishing a TCP/IP communication session between a client computer and a 
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first server computer, said first server computer part of a plurality of server computers forming a 
web cluster containing information, said communication session established for the transfer of 
data contained within said information; 

b) monitoring traffic associated with establishing said TCP/IP communication 
session to understand a first initial TCP state of said first server computer associated with said 
TCP/IP communication session, at a first bottom-TCP (BTCP) module at said first server 
computer; 

c) receiving a web request associated with said TCP/IP communication session at 
said first BTCP module at said first server computer; 

d) examining content of said web request; 

e) determining which of said plurality of server computers, a selected server 
computer, can best process said web request, based on said content; 

f) handing off said communication session to said selected server computer from 
said first server computer over a persistent control charmel, if said selected server computer is 
not said first server computer; 

g) monitoring traffic associated with handing off said TCP/IP communication 
session to understand a second initial TCP state of said selected server computer associated with 
said TCP/IP communication session, at a second BTCP module at said selected serv^er computer; 

h) migrating said first initial TCP state to said selected server computer over said 
control channel, such that said second BTCP module can calculate a first TCP state for said first 
sen'er computer in said TCP/IP communication session; 

i) sending a second initial TCP state of said selected server computer to said first 
BTCP module, such that said first BTCP module can calculate a second TCP state for said 
selected server computer in said TCP/IP communication session; 

j) forwarding data packets received at said first BTCP module from said client to 
said selected server computer, by changing said data packets to reflect said second TCP state and 
a second IP address of said selected server computer; 

k) sending response packets fi-om said selected server computer directly to said 
client computer by changing said response packets to reflect said first TCP state and a first IP 
address of said first server computer; and 
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1) tenttinating said TCP/IP communication session at said first server computer 
when said TCP/IP communication session is closed. 

12. The method as described in Claim 1 1 , wherein said step a) comprises the steps of: 
receiving a packet from said client at said first BTCF module; 

sending said SYN packet upstream to a first TCP module located above said first BTCP 
module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state firom said first SYN/ACK packet, including a first 
initial sequence number for said first TCP module associated with, said TCP/IP communication 
session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 

storing said SYN, ACK and said web request at said first server computer, 

1 3 . The method as described in Claim 1 1 , wherein said step e) comprises the steps of: 
sending a handoff request packet from said first BTCP module to said second BTCP 

module over said control channel; 

including said SYN packet and said ACK packet in said handoff request packet; 

changing a first destination IP address of said SYN packet to a second IP address of said 
selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, including a 
second initial sequence number, for said second TCP module, that is associated with said TCP/IP 
communication session; 

changing a second destination IP address of said ACK packet to said second IP address, 
at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 
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14. The method as described in Claim 13, wherein said ACK packet includes said 
first initial TCP state of said first server computer as provided for in step f). 

15. Tiie method as described in Claim 13, wherein said handoff acknowledgment 
includes said second initial TCP state of said second server computer, including a second initial 
sequence number, for said second TCP module, that is associated with said TCP/IP 
communication session as provided for in step i). 

16. The method as described in Claim 13, comprising the further steps of: 
intercepting a connection indication message sent fi:om said first TCP module to an 

application layer above said first TCP module at a first upper-TCP (UTCP) module, said 
connection indication message sent by said first TCP module upon establishing said 
communication session; and 

holding said connection indication message at said first UTCP module. 

17. The method as described in Claim 1 6, wherein step h) comprises the further steps 

of: 

sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module; 

discarding said coraiection indication message at said first UTCP module; 

receiving incoming data packets from said client at said first BTCP module; 

changing said destination addresses of said incoming data packets to said second IP 
address; 

updating sequence numbers and TCP checksum in said data packets to reflect said second 
TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

18. The method as described in Claim 1 1, wherein step k) comprises the steps of: 
intercepting outgoing response packets from said selected server computer at said second 

BTCP module; 

changing source addresses of said response packets to said first IP address; 

updating sequence numbers and TCP checksum in said response packets to reflect said 
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first TCP state of said first server computer; and 

sending said updated response packets to said client. 

19. The method as described in Claim 11, wherein step 1) comprises the steps of: 
monitoring TCP/IP control traffic for said communication session at said second BTCP 

module; 

understanding when said communication session is closed at said second server 
computer; 

sending a temiination message to said first server computer over said control channel; 
ten-ninating a forwarding mode at said first BTCP module; and 
freeing data resources associated with said communication session at said first server 
computer. 

20. The method as described in Claim 1 6, comprising the further steps of: 
sending notification fi:om said first BTCP module to said first UTCP module to release 

said connection indication message, if said selected ser\'er computer is said first server computer; 
and 

sending incoming data packets, including said web request, from said client, received at 
said first BTCP module, upstream. 

2 1 . The method as described in Claim 1 1 , wherein each of said plurality of server 
computers is constructed similarly including BTCP modules located downstream from TCP 
modules, and UTCP modules located upstream fi-om TCP modules. 

22. The method as described in Claim 12, comprising the further step of storing said 
web request, said SYN packet, said ACK packet, and said web request at said first server 
computer. 

23. The method as described in Claim 22, wherein said control channel allows for 
communication between all UTCP modules. 
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24. The method as described in Claim 1 1 , wherein said plurality of server computers 
is coupled together over a wide area network in said communication network, 

25. The method as described in Claim 11, wherein said information is 
partitioned/partially replicated througliout each of said plurality of server computers. 
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26. A server computer comprising: 

an upper TCP (UTCP) module located above a TCP module in an operating system of 
said server computer; 

a bottom TCP (BTCP) module located below said TCP module, said UTCP, TCP, and 
BTCP modules implementing a method of handing off a communication session between a first 
node and second node in a cluster network that works within the kernel level of an existing 
TCP/IP protocol, by migrating TCP states associated with said first and second nodes. 

27. The server computer as described in Claim 26, wherein said method comprises 
the steps of: 

a) establishing a TCP/IP communication session between a client computer and said 
server computer, said first node, said server computer part of a plurality of server computei-s 
forming said cluster network containing information, said communication session established for 
the transfer of data contained within said information; 

b) receiving a web request associated with said TCP/IP communication session at a 
first BTCP module at said server computer; 

c) examining content of said web request; 

d) determining which of said plurality of server computers, a selected server 
computer, can best process said web request, based on said content; 

e) handing off said communication session to said selected server computer from 
said server computer over a persistent control channel, if said selected server computer is not 
said server computer; and 

f) migrating a first TCP state of said sender computer to said selected server 
computer, and sending a second TCP state of said selected server computer to said server 
computer over said control channel. 

28. The server computer as described in Claim 27, wherein step a) of said method 
comprises the steps of: 

receiving a SYW packet from said client at said BTCP module; 
sending said SYN packet upstream to said TCP module; 
receiving a first SYN/ACK packet from said TCP module; 
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parsing a first initial TCP state from said first SYN/ACK packet, including a first initial 
sequence number for said TCP module associated with said TCP/IP communication session; 
sending said SYN/ACK packet to said client; 
receiving an ACK packet from said client at said BTCF module; 
sending said ACK packet to said TCP module; 
storing said SYN, ACK at said server computer. 

29. The server computer as described in Claim 28, wherein said method comprises 
the steps of: 

sending a handoff request packet from said BTCP module to a second BTCP module over 
said control channel, said second BTCP module located below a second TCP module in a second 
operating system at said selected server computer; 

including said SYN packet and said ACK packet in said handoff request; 

receiving a handoff acknowledgment message at said BTCP module from said second 
BTCP module. 

30. The server computer as described in Claim 29, wherein said step 1) of said method 
comprises the steps of 

monitoring traffic associated with establishing said TCP/IP communication session in 
step a), at said BTCP module, to parse a first initial TCP state of said ser\^er computer, said first 
initial TCP state associated with said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over said control 
channel by including said first initial TCP state in said handoff request, said first initial TCP state 
including a first sequence number, such that said second BTCP module can calculate said first 
TCP state for said server computer in said TCP/IP communication session, 

3 1 . The server computer as described in Claim 29, wherein said method comprises 
the further steps of: 

intercepting a connection indication message sent from said first TCP module to an 
application layer above said first TCP module at a first upper-TCP (UTCP) module, said 
connection indication message sent by said first TCP module upon establishing said 
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communication session; and 

holding said connection indication message at said first UTCP module. 

32. The computer system as described in Claim 3 1 , wherein said method comprises 
the further steps of: 

sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 

receiving incoming data packets fi-om said client at said first BTCP module; 

changing said destination addresses of said incoming data packets to said second IF 
address; 

updating sequence numbers and TCP checksum in said data packets to refiect said second 
TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

33. The sender computer as described in Claim 3 1 , said method comprising the farther 
steps of: 

sending notification from said BTCP module to said UTCP module to release said 
connection indication message, if said selected server computer is said server computer; 

sending incoming data packets, including said web request, from said client, received at 
said first BTCP module, upstream. 

34. The sers'er computer as described in Claim 26, said metliod comprising the further 
steps of: 

receiving a handoff request from a first BTCP module located at a first server computer 
within said cluster network over a persistent control channel, said first server computer having 
established a communication session with a client computer, said communication session 
established for the transfer of data contained within said server computer, said handoff request 
including a SYN packet and an ACK packet, said SYN and ACK packet used for establishing 
said communication session between said client and said first server computer, said ACK packet 
including a first initial TCP state of said first server computer in said communication session, 
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including a first initial TCP sequence number; 

changing a first destination IP address of said SYN packet to a second IP address of said 
server computer, at said BTCP module; 

sending said SYN packet to said TCP module; 

receiving a SYN/ACK packet at said second BTCP module; 

parsing a second initial TCP state from second SYN/ACK packet, including a second 
initial sequence number, for said TCP module, said second initial TCP state associated with a 
second TCP state for said server computer in said TCP/IP communication session; 

changing a second destination IP addi-ess of said ACK packet to said second IP address, 
at said BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 

sending said ACK packet that is updated to said TCP module; and 

sending a handoff acknowledgment message to said first BTCP module over said control 
channel. 

35. The server computer as described in Claim 34, wherein said method comprises 
the further steps of: 

monitoring traffic associated with handing off said TCP/IP communication session to 
said server computer, at said BTCP module, to parse said second initial TCP state of said server 
computer, said second initial TCP state associated with said TCP/IP communication session; and 

sending said second initial TCP state of said server computer to said first BTCP module 
by including said second initial TCP state in said handoff actaiowledgment, said second initial 
TCP state including a second initial sequence number, such that said first BTCP module can 
calculate said second TCP state for said server computer in said TCP/IP communication session, 

36. The server computer as described in Claim 34, wherein said method comprises 
the further steps of: 

intercepting outgoing response packets from said server computer at said second BTCP 
module; 

changing source addresses of said response packets to said first IP address; 

25S06400.1 59 



Application No.: 09/880,631 



Docket No.: 10010812-1 



updating sequence numbers and TCP checksum in said response packets to reflect said 
first TCP state of said first server computer; and 

sending said response packets to said client. 
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37. The sei-ver computer as described in Claim 34, wherein said method comprises 
the further steps of: 

monitoring TCP/IP control traffic for said communication session at said BTCP module; 
understanding when said communication session is closed at said server computer; and 
sending a termination message to said first server computer over said control channel. 
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APPENDIX B 

No evidence pursuant to §§ 1 . 1 30, 1 . 1 3 1 , or 1 . 1 32 or entered by or relied upon by the 
examiner is being submitted. 
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APPENDIX C 

No related proceedings are referenced in 11. above, hence copies of decisions in related 
proceedings are not provided. 
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